home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0088.001 < prev    next >
Text File  |  1995-10-31  |  13KB  |  309 lines
  1.  
  2.   | Document: FSC-0088
  3.   | Version:  001
  4.   | Date:     31 October, 1995
  5.   |
  6.   | Robert Williamson FidoNet#1:167/104.0
  7.  
  8.     Compatibility and Link Qualifier Extensions for EMSI Sessions
  9.     Robert Williamson FidoNet#1:167/104.0  robert@ecs.mtlnet.org
  10.  
  11.     Purpose:
  12.  
  13.     The  basic  purpose of this document is to start discussions which will
  14.     hopefully result in an improved handshake negotiation protocol.
  15.  
  16.     Scope:
  17.  
  18.     Relation of flags to Types of files transferred:
  19.  
  20.     The  FSC-0056  EMSI  specification  (hereafter  referred  to as EMSI-I)
  21.     makes  little  distinction  between  ARCmail/packets and other types of
  22.     files,  such  as  files attached and TIC'ed files.  In EMSI-I, the term
  23.     'Mail'  when  not  used  in  conjunction with the term 'compressed', is
  24.     interpreted to mean ANY file.
  25.  
  26.     This  extension  (hereafter  referred to as EMSI-II) makes reference to
  27.     and  allows control of types of files in addition to 'compressed mail'.
  28.     References  to  'Mail'  are  changed to 'File' where common practice so
  29.     indicates.   The  additional qualifier flags described provide for more
  30.     control as to the types of files a system is prepared to receive.
  31.  
  32.  
  33.     Relation of flags to presented addresses:
  34.  
  35.     The  EMSI-I  specification does not allow qualification for any address
  36.     other than the PRIMARY address.  This means that Link flags are limited
  37.     in  application  to  either  all  presented addresses or to the primary
  38.     presented address only.
  39.  
  40.     This  extension  also  allows  application  of  Link  flags to specific
  41.     addresses other than the primary.
  42.  
  43.  
  44.     Distinctions between Calling and Answering System:
  45.  
  46.     In  the EMSI-I spec, the type of flags that may be presented is limited
  47.     by  the  status  of the site.  Certain flags may only be presented when
  48.     the  site  is the caller and other flags may only be presented when the
  49.     site   is   the   answerer.    This  proposed  extension  removes  this
  50.     distinction.
  51.  
  52.     In the EMSI-I spec, certain Link and Capability (a.k.a:  Compatibility)
  53.     flags  are  caller-driven, while others are controlled by the answering
  54.     system.  This specification attempts to harmonize these discrepancies.
  55.  
  56.     A  attempt  is made to remain somewhat backwards compatible and to have
  57.     new  flags  follow the original flag naming convention.  However, IMHO,
  58.     it  would  be preferable to harmonize the flags; reducing the number of
  59.     them  while retaining the fine type control, so that the same codes are
  60.     used in all sessions.
  61.  
  62.     Under  both  EMSI-I and EMSI-II, any flags that are not understood, are
  63.     to  be  ignored.   Therfore,  if  a site presents it's flags in EMSI-II
  64.     format  and  the  other site does not do EMSI-II, it is permissable for
  65.     that site to interpret all flags according to EMSI-I specifications.
  66.  
  67.  
  68.     Specifics:
  69.  
  70.     Compatibility flags:
  71.  
  72.     Compatibility  flags  consist of a string of codes that specify the
  73.     PROTOCOL CAPABILITIES and ENABLED FEATURES of the mailer.
  74.  
  75.     ARC, XMA
  76.     These  EMSI-I  compatibility  flags  have  no  meaning  relavant to the
  77.     transfer  of  files  and  are  not  to  be presented under EMSI-II.  If
  78.     received, they are to be ignored.
  79.  
  80.  
  81.     FNC    
  82.     The FNC EMSI-I compatibility flag has been identified as a 'mistake' by
  83.     the  author  of EMSI-I.  This is agreeable as that specification called
  84.     for   the   creation   of   a   filename   that  was  ALWAYS  8.3,  not
  85.     up-to-8.up-to-3.
  86.     It   is   not  to  be  presented  under  EMSI-II.   If  received  as  a
  87.     compatibility flag, it is to be ignored.
  88.  
  89.  
  90.     Protocol Selection:
  91.  
  92.     In  the EMSI-I spec, a requirement is placed upon the calling system to
  93.     present  it's  available  protocols  in  order  of preference.  A quote
  94.     follows:
  95.  
  96.         The calling system must list supported protocols first and
  97.         descending order of preference (the most desirable protocol
  98.         should be listed first).
  99.         The answering system should only present one protocol and it
  100.         should be the first item in the compatibility_codes field.
  101.  
  102.     Some mailer authors have interpreted 'the compatibility_codes field' in
  103.     the  second  sentence  to  mean  that  of the answering system, thereby
  104.     making  protocol  selection RECEIVER-PREFS driven.  This interpretation
  105.     makes  unnecessary  the  'decending  order' requirement placed upon the
  106.     calling   system,   so  shall  be  considered  in  conflict  with  that
  107.     requirement.
  108.  
  109.      Most   mailer  authors  have  interpreted  that  phrase  to  mean  the
  110.     'compatibility_codes  field'  OF  THE  CALLER,  thereby making protocol
  111.     selection  CALLER-PREFS  driven.   Since  EMSI-I  was intended to be "a
  112.     clear  protocol  definition  for  state-of-the-art  E-Mail  systems  to
  113.     follow",  they  cannot  be  faulted  for  interpretation.  Caller-prefs
  114.     driven  selection  is state-of-the-art, receiver-prefs driven selection
  115.     is older technolgy, such as Wazoo.
  116.  
  117.     This   specification   requires   that   the   second  interpretation,
  118.     CALLER-PREFS driven, be mandatory.
  119.  
  120.  
  121.     New Compatibilty Flags:
  122.     ----------------------
  123.  
  124.     EII
  125.     Indicates   that   the   system   will   interpret   flags  under  this
  126.     specification, if other end also presents this flag.  IF either or both
  127.     systems  do  not  present  this  flag,  all  interpretations  are  done
  128.     according to EMSI-I.
  129.  
  130.     DFB
  131.     Indicates  that  the  system  presenting  is  capabable of fall-back to
  132.     FTS1/WAZOO  negotiation  in the case of failure of EMSI handshake or no
  133.     common  protocol.   Since  ZMO  is  the  minimum required protocol, NCP
  134.     should  only  occur  if  the  answering  system  presents more than one
  135.     protocol..  (ie. it's broken)
  136.  
  137.     FRQ
  138.     Indicates  that  the  system  will  accept  and  process  file requests
  139.     received  during  outbound  calls.   In other words, the calling system
  140.     will  do a second turnaround for uni-directional protocols, to send the
  141.     files requested, at his cost.
  142.  
  143.     NRQ
  144.     NRQ should be presented ONLY IF the mailer does not have a file request
  145.     server, task or function and cannot accept requests..  It should NOT be
  146.     used to indicate that the  function  is  temporarly disabled. 
  147.  
  148.     When  examined,  No  requests will be sent.  It would be advisable that
  149.     the  mailer  alert  the  system  operator  of this occurance to prevent
  150.     continued polling of the remote site.
  151.  
  152.  
  153.     Protocol Capabilities:
  154.  
  155.     Protocol   capability   flags  are  presented  in  decending  order  of
  156.     preference  by  the  caller.  The answering system selects and presents
  157.     the  FIRST  protocol  from  the  callers  list  that  it supports.  The
  158.     answering system must present only ONE protocol.
  159.  
  160.     HYD  Hydra bi-directional    (link flags define parameters)
  161.     JAN  Janus bi-directional
  162.     TZA  DirectZap               (TrapDoor DirectZap varient)
  163.     DZA  DirectZap               (Zmodem variant, reduced escape set)
  164.     ZAP  ZedZap                  (Zmodem variant, upe 8K blocks)
  165.     ZMO  Zmodem w/1,024 packets  (Wazoo ZedZip)
  166.     SLK  SeaLink                 (no TYSNC, No MDM7, No TeLink)
  167.                                  (8-32k window/ReSync/OverDrive/LongNames)
  168.  
  169.     NCP
  170.     This  is  presented  if  no compatible protocol can be negotiated under
  171.     EMSI.   Since  in  most  FTN  networks,  a  common protocol DOES exist,
  172.     fallback   to  WaZoo  and  FTS1  negotiation  is  expected.   If  these
  173.     negotiation methods are not available, the session is terminated.
  174.  
  175.     This  condition  should  never  occur  under  normal circumstances.  It
  176.     should  be  considered as a problem with the design or configuration of
  177.     one of the mailers involved.
  178.  
  179.     Link flags:
  180.     ----------
  181.  
  182.     Link  flags  consist  of a string of codes that specify DESIRED CONNECT
  183.     CONDITIONS.   They  apply  to  the CURRENT SESSION ONLY.  Under EMSI-I,
  184.     there are four TYPES of link flags:  communications parameters, session
  185.     parameters, pickup options and hold options.  Under EMSI-II, only three
  186.     types  are  used,  the communications parameters type is REMOVED, as it
  187.     serves no purpose whatsoever in FTN operations.
  188.  
  189.  
  190.     Link Session options:
  191.  
  192.     FNC
  193.     If  either  system  presents  this  flag,  it is an indication that the
  194.     presenting   system   requires   filename   conversion   to  cp/m-msdos
  195.     conventions.  The other system will convert filenames to cp/m cpm/msdos
  196.     8.3 conventions before sending. 
  197.     The   convention   is   defined   as   a  filename  consisting  of  two
  198.     parts,  the  filepart  and  extension.   The filepart and extension are
  199.     separated  by a period ".".  The filepart may be from 1 to 8 characters
  200.     in  length  and  the  extension  may  be  from  0 to 3 characters.  The
  201.     character set shall be any uppercase character in the range A-Z and any
  202.     numeric  character  in  the  range  0-9.   If  the extension is of zero
  203.     length, the period may or may not be present.
  204.  
  205.  
  206.     RMA
  207.     Indicates that the presenting site is able to send and process multiple
  208.     file  requests.   If both sites present this flag, the caller will send
  209.     any REQ files found for each AKA presented by the answering system.
  210.     The answering system will process each received REQ.
  211.  
  212.     RH1
  213.     Indicates  that  under  the  Hydra  protocol,  batch  one contains file
  214.     requests only, while batch 2 is reserved for all other files.
  215.     
  216.  
  217.     (others to be defined)
  218.  
  219.     Pickup and Hold Flags:
  220.  
  221.     Under  the  EMSI-I  specification, Link Pickup flags are only presented
  222.     when  calling (an Outbound Session) and are examined and processed only
  223.     when  answering  (an  Inbound  Session)  and  Link  Hold flags are only
  224.     presented  when  answering  (an  Inbound  Session) and are examined and
  225.     processed only when calling (an Outbound Session).
  226.  
  227.     With  EMSI-II,  BOTH  Pickup and Hold flags are presented by both sites
  228.     during  a  session.   This  allows  more control for those systems, for
  229.     example,  which  cannot  modify  addresses  presented or rotate akas to
  230.     change  the  primary  address  presented  on  a per-session or per-site
  231.     basis.
  232.  
  233.  
  234.     Link Pickup and Hold:
  235.  
  236.     Each  system can present one of three (or more) Link options related to
  237.     application of addresses.  If neither of these flags are presented, PUA
  238.     is to be assumed.
  239.  
  240.     Neither  PUA  nor  PUP  is  to  be  presented  if  only one address was
  241.     presented.
  242.  
  243.              PUP     Pickup FILES for primary address only
  244.           /  PUA     Pickup FILES for all presented addresses
  245.          /   PUn     Pickup FILES for address number n in AKA list
  246.  one of |
  247.          \
  248.           \  NPU     No FILE pickup desired. (calling system)
  249.              HAT     Hold all FILES          (answering system)    
  250.              HAn     Hold all FILES for address number n in AKA list
  251.  
  252.  
  253.     Qualifiers:
  254.  
  255.     Qualifiers  are  processed  in  the  order presented, with any conflict
  256.     being  resolved  by  subsequent  qualifiers overridding any conflicting
  257.     previous qualifier in the list.
  258.  
  259.     Qualifiers may be not be presented with either NPU or HAT and should be
  260.     ignored if received with NPU or HAT.
  261.  
  262.     PickUp:
  263.  
  264.         PMO     PickUp Mail (ARCmail and Packets) ONLY 
  265.         PMn     PickUp Mail ONLY for address number n in AKA list
  266.  
  267.         NFE     No TIC'S, associated files or files 
  268.                 attachs desired
  269.         NFn     No TIC'S, associated files or file attaches, 
  270.                 for address number n in AKA list
  271.  
  272.         NXP     No compressed mail pickup desired 
  273.         NXn     No compressed mail pickup desired, 
  274.                 for address number n in AKA list
  275.  
  276.         NRQ     File requests not accepted by caller
  277.                 This  flag is presented if file request processing
  278.                 is disabled TEMPORARILY for any reason
  279.         NRn     File requests not accepted by caller
  280.                 for address number n in AKA list
  281.  
  282.      Note that NFE,NPX,NRQ != NPU
  283.  
  284.     Hold:
  285.  
  286.         HNM     Hold all traffic EXCEPT Mail (ARCmail and Packets)
  287.         HNn     Hold all traffic EXCEPT Mail (ARCmail and Packets)
  288.                 for address number n in AKA list
  289.  
  290.         HXT     Hold compressed mail traffic.
  291.         HXn     Hold compressed mail traffic.
  292.                 for address number n in AKA list
  293.  
  294.         HFE     Hold tic's and associated files
  295.                 and file attaches other than mail 
  296.         HFn     Hold tic's and associated files
  297.                 and file attaches other than mail 
  298.                 for address number n in AKA list
  299.  
  300.         HRQ     Hold file requests (not processed at this time)
  301.                 This  flag is presented if file request processing
  302.                 is disabled TEMPORARILY for any reason
  303.         HRn     Hold file requests (not processed at this time)
  304.                 for address number n in AKA list
  305.  
  306.      Note that HXT,HRQ,HFE == HAT
  307.  
  308.     -eot-
  309.